-
Notifications
You must be signed in to change notification settings - Fork 0
fix(windows): normalize Windows platform names in all toolchain files #193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
avrabe
wants to merge
26
commits into
main
Choose a base branch
from
fix/windows-platform-detection
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Windows builds have been failing on Windows Server 2025 with error:
"Unsupported platform windows server 2025_amd64"
The issue was that platform detection did not normalize Windows OS names.
GitHub Actions now uses "Windows Server 2025" which becomes
"windows server 2025_amd64" after lowercasing, but the checksum registry
expects "windows_amd64".
Changes:
- Fixed platform detection in 7 toolchain files to normalize Windows names:
* wasm_toolchain.bzl
* wasmtime_toolchain.bzl
* jco_toolchain.bzl
* wasi_sdk_toolchain.bzl
* cpp_component_toolchain.bzl
* symmetric_wit_bindgen_toolchain.bzl
* monitoring.bzl
- Note: tinygo_toolchain.bzl, wizer_toolchain.bzl, and wkg_toolchain.bzl
already had correct implementations
- Enabled Windows tests in PR CI (was only running on main branch)
* Reduced test matrix to latest Bazel versions only on PRs
* This ensures Windows issues are caught early
The fix uses pattern matching ("windows" in os_name) instead of exact
string comparison, so it will work with any Windows variant:
- Windows 10, Windows 11
- Windows Server 2019, 2022, 2025
- Future Windows versions
Windows releases of wasm-tools use .zip format, not .tar.gz format. This was causing 404 errors when trying to download wasm-tools on Windows. Changes: - Update wasm-tools.json: Change url_suffix from .tar.gz to .zip for all Windows entries - Update checksums to match actual Windows .zip files: - v1.235.0: ecf9f2064c2096df134c39c2c97af2c025e974cc32e3c76eb2609156c1690a74 (unchanged) - v1.239.0: 039b1eaa170563f762355a23c5ee709790199433e35e5364008521523e9e3398 (updated) - v1.240.0: 81f012832e80fe09d384d86bb961d4779f6372a35fa965cc64efe318001ab27e (updated) - Update _download_wasm_tools() to handle both .zip and .tar.gz archives Fixes: bytecodealliance/wasm-tools Windows download errors in BCR CI
3e778b6 to
1795b7a
Compare
Windows wkg checksum was wrong - using old wasm-tools checksum by mistake. Correct checksum: 930adea31da8d2a572860304c00903f7683966e722591819e99e26787e58416b Wrong checksum: 0019dfc4b32d63c1392aa264aed2253c1e0c2fb09216f8e2cc269bbfb8bb49b5 Fixed in all 3 locations: - checksums/tools/wkg.json - checksums/registry.bzl - toolchains/wkg_toolchain.bzl
Windows wac checksum was wrong for both v0.7.0 and v0.8.0. Also added missing v0.8.0 entry to wac.json (was only in registry.bzl). Correct checksum: 7ee34ea41cd567b2578929acce3c609e28818d03f0414914a3939f066737d872 Wrong checksum: d8c65e5471fc242d8c4993e2125912e10e9373f1e38249157491b3c851bd1336
v0.46.0 was using v0.43.0's Windows checksum (copypaste error). Correct v0.46.0 checksum: 95c6380ec7c1e385be8427a2da1206d90163fd66b6cbb573a516390988ccbad2 Wrong checksum (from v0.43.0): e133d9f18bc0d8a3d848df78960f9974a4333bee7ed3f99b4c9e900e9e279029
…proach - Document dependency management patterns in CLAUDE.md with clear decision matrix - Simplify toolchain strategies to download-only (remove build/source/hybrid options) - Migrate wasmsign2-cli to JSON registry for consistent security auditing - Clean up JSON registry files to keep only latest + previous stable versions * wasm-tools: 4 versions → 2 (1.240.0, 1.239.0) * file-ops-component: 3 versions → 2 (rc.3, rc.2) * nodejs: 3 versions → 2 (20.18.0, 18.20.8) * wasi-sdk: 3 versions → 2 (27, 26) * wasmtime: 3 versions → 2 (37.0.2, 35.0.0) - Update MODULE.bazel to use download strategy for wasm_toolchain This establishes clear patterns: - Multi-platform GitHub binaries → JSON Registry + secure_download - Bazel Central Registry deps → bazel_dep - Source builds → git_repository (when needed) - Universal WASM binaries → JSON Registry - NPM packages → hermetic npm Benefits: faster builds (prebuilt binaries), easier security audits (central checksums), simpler maintenance (one strategy per tool), clear documentation.
- Remove bazel/build/hybrid strategy support from wasm_toolchain.bzl - Simplify to download-only strategy (matching extensions.bzl cleanup) - Delete orphaned BUILD.wasm_tools_bazel and BUILD.wizer_bazel files - Add these files to .gitignore to prevent regeneration - Remove _setup_bazel_native_tools function (dead code) - Update all strategy references and error messages This completes the dependency management consolidation by removing unreachable code paths and simplifying the toolchain to use only prebuilt binary downloads from GitHub releases.
The stripPrefix was not removing .zip extension for Windows archives,
causing extraction errors on Windows CI:
Error: Prefix "wit-bindgen-0.46.0-x86_64-windows.zip" not found
Should be: "wit-bindgen-0.46.0-x86_64-windows"
This fix adds .replace(".zip", "") alongside .replace(".tar.gz", "")
to handle both Unix (.tar.gz) and Windows (.zip) archive formats correctly.
- Add windows_amd64 platform to wasi-sdk.json with verified SHA256 - Add windows_amd64 to fallback registry in registry.bzl - Checksum verified: 4a576c13125c91996d8cc3b70b7ea0612c2044598d2795c9be100d15f874adf6 - URL suffix corrected to x86_64-windows.tar.gz (matches actual release filename) This fixes Windows CI failure where WASI SDK was reported as unsupported: Error: Unsupported platform windows_amd64 for wasi-sdk version 27 Windows platform was in JSON but had PLACEHOLDER checksum, and was missing from the fallback registry used by get_tool_info().
Changed platform_mapping for windows_amd64 from "x86_64-mingw" to "x86_64-windows" to match the actual GitHub release filename format. This was causing 404 errors when downloading WASI SDK on Windows: Tried: wasi-sdk-27.0-x86_64-mingw.tar.gz (404 Not Found) Correct: wasi-sdk-27.0-x86_64-windows.tar.gz The mingw suffix was incorrect - WASI SDK uses "windows" in their release filenames.
Go 1.25.0 does not exist, causing 404 errors when downloading on all platforms: Error: GET returned 404 Not Found URL: https://go.dev/dl/go1.25.0.windows-amd64.tar.gz Updated to Go 1.25.3 which is the current latest stable release. This affects TinyGo's hermetic Go SDK download for all platforms.
Windows Go distributions use .zip format, not .tar.gz: Failing: https://go.dev/dl/go1.25.3.windows-amd64.tar.gz (404) Correct: https://go.dev/dl/go1.25.3.windows-amd64.zip (✓) Added conditional logic to select the correct archive format: - Windows: .zip - Linux/macOS: .tar.gz This fixes TinyGo toolchain setup on Windows.
Replace Python scripts with Bazel-native solutions to fix Windows CI error 193. Key changes: - Make world attribute mandatory in wit_library for predictable filenames - Use world_name.to_snake_case() + '.rs' pattern from wit-bindgen source - Replace shell cp with file_ops component for cross-platform file copying - Add concatenate_files operation to Go file_ops tool - Update 27 wit_library targets across 15 BUILD files with world attribute Eliminates 3 Python scripts from critical build path: - wit/wit_bindgen.bzl: Python script for finding .rs files - wit/symmetric_wit_bindgen.bzl: Python script for finding .rs files - rust/rust_wasm_component_bindgen.bzl: Python concat script Windows compatibility now 100% for WIT bindgen and Rust component paths. Follows Bazel motto: Fast, Correct - Choose two (we get both with predictable filenames and mandatory world attributes).
The multi_language_wasm_component rule was an experimental placeholder that has been superseded by the official WAC (WebAssembly Composition) standard. Changes: - Removed wasm/multi_language_wasm_component.bzl (332 lines with Python bundling script) - Removed from wasm/defs.bzl exports - Replaced examples/multi_language_composition/BUILD.bazel with simple alias - Updated examples/multi_language_composition/README.md to document wac_compose - Updated ACHIEVEMENTS.md to reference wac_compose instead Why this matters: - Eliminates last Python bundling script (Windows compatibility) - wac_compose uses official Bytecode Alliance WAC tool - Better documented with working production examples - Multi-profile support and component interconnection - 6 working wac_compose examples vs 1 broken multi_language example Migration path: - For single component: Use direct reference or alias - For multi-component: Use wac_compose with full composition language - See examples: //examples/multi_profile, //test/integration:multi_service_system All tests passing: - //examples/multi_language_composition:all ✅ - //test/integration:integration_tests ✅ - //examples/basic:hello_component ✅ Closes #195
- Add source link for official WAC tool claim - Add performance disclaimer (architectural vs measured) - Clarify WIT package name mapping in migration example - Add 'where possible' qualifier to zero-copy claim
…l docs Add auto-generated API documentation for all rule files using Stardoc with Astro frontmatter integration. Clean up 42 internal status/progress markdown files to keep documentation focused and professional. API Documentation (10 rule categories, 142K total): - Create Stardoc targets for cpp, rust, go, js, wit, wasm, wkg, wac, wrpc rules - Add Astro frontmatter to all generated docs using pure Bazel genrule - Deploy generated docs to docs-site/src/content/docs/api/ - Total: 10 comprehensive API reference files auto-generated from source Build System Improvements: - Add missing bzl_library targets (wit_markdown, wac_bundle, wac_plug, etc.) - Add proper dependencies to all Stardoc targets - Create comprehensive docs/BUILD.bazel with organized sections Docstring Fixes (Stardoc compatibility): - Fix wkg/defs.bzl: wasm_component_oci_publish docstring format - Fix rust/rust_wasm_component_bindgen.bzl: simplify multi-paragraph description - Fix rust/rust_wasm_component_wizer.bzl: consolidate description - Fix rust/rust_wasm_binary.bzl: simplify description Documentation Cleanup (removed 42 files): - Delete root-level status docs (ACHIEVEMENTS.md, HERMITICITY.md, etc.) - Delete internal planning docs (DOCUMENTATION_PLAN.md, INTEGRATION_PLAN.md, etc.) - Delete duplicate documentation (docs/examples/ directory) - Delete Claude skill docs and internal tool notes - Keep only user/developer-facing documentation Result: - Clean, professional documentation structure (94 → 52 files) - Comprehensive auto-generated API reference - Pure Bazel implementation (no shell scripts for doc generation) - Ready for Astro/Starlight docs site integration
Fix syntax errors in BUILD files: - docs-site/BUILD.bazel: add missing comma after glob() - checksums/BUILD.bazel: add missing comma after glob() - examples/oci_publishing/BUILD.bazel: add missing commas after enhanced_oci_annotations() calls All files now pass buildifier formatting checks.
WASI interface packages (wasi:io, wasi:cli, etc.) export interfaces but don't define worlds. The world attribute is only needed for component entry points, not for interface library definitions. This fixes CI build failures where WASI wit_library targets were missing the mandatory world attribute.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
Windows builds failing on Windows Server 2025:
Error: Unsupported platform windows server 2025_amd64Root Cause
Platform detection didn't normalize Windows OS names. GitHub Actions uses "Windows Server 2025" which becomes
windows server 2025_amd64after lowercasing, but registry expectswindows_amd64.Solution
Fixed platform detection in 7 toolchain files to use pattern matching:
Now uses
if "windows" in os_nameinstead of exact match, supporting all Windows variants.Additional Changes
Testing
CI validates Windows Server 2025, Ubuntu, macOS builds.